Terrain - dedicated OSD element - #11846

• Adds a dedicated Terrain AGL OSD item independent of rangefinder health.
• Displays terrain altitude with a distinct icon and dashes when data is unavailable.
• Documents selection and troubleshooting of dedicated versus fallback terrain displays.

graph TD
    T["Terrain Tiles"] --> S["Terrain Subsystem"] --> R["OSD Renderer"] --> A["Terrain AGL"]
    F["Rangefinder"] --> R --> D["Rangefinder Distance"]

Loading

A separate appended OSD item is the best approach because it preserves existing rangefinder-first behavior and numeric item compatibility while allowing pilots to monitor terrain-derived AGL independently. Retaining only the overloaded rangefinder element would not satisfy that use case.

Enhancement (2) +16 / -2

osd.cRender terrain-only altitude in the OSD +15/-2

Render terrain-only altitude in the OSD

• Adds feature-gated rendering for the dedicated Terrain AGL item using the terrain subsystem directly. Valid values use altitude formatting and the terrain symbol; unavailable values display dashes.

src/main/io/osd.c

osd.hRegister the Terrain AGL OSD item +1/-0

Register the Terrain AGL OSD item

• Appends OSD_TERRAIN_AGL as item 171 and advances the OSD item count, exposing the new element without renumbering existing items.

src/main/io/osd.h

Documentation (1) +9 / -5

Terrain.mdDocument dedicated Terrain AGL display behavior +9/-5

Document dedicated Terrain AGL display behavior

• Explains the distinction between the terrain-only OSD element and the existing rangefinder-first element. Troubleshooting guidance now names both possible terrain displays.

docs/Terrain.md

Description

Appending OSD_TERRAIN_AGL changes every row's stride in the persisted two-dimensional item_pos
array, but the unchanged parameter-group version causes old bytes to be copied directly into the
enlarged structure. After upgrade, layout 0's first value is consumed as the new terrain slot and
every subsequent alternate-layout item is shifted, changing positions/visibility and assigning
values to the wrong OSD elements.

Code

src/main/io/osd.h[382]

+    OSD_TERRAIN_AGL, // 171,

Evidence

There are four layout rows, and the added enum increases each row from 171 to 172 entries. The
registered storage version remains 3, while pgLoad accepts that same version and copies the old
payload contiguously; because C stores the 2D array row-major, only the first row remains aligned
and each following row is shifted by the new per-row slot.

src/main/io/osd.h[27-30]
src/main/io/osd.h[379-383]
src/main/io/osd.h[448-451]
src/main/io/osd.c[235-236]
src/main/config/parameter_group.c[86-93]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Adding an item changes the stride of each row in persisted `item_pos[OSD_LAYOUT_COUNT][OSD_ITEM_COUNT]`. Because the registered PG version remains 3, old four-layout payloads are copied as a flat prefix into the new shape and alternate layouts become misaligned.
## Issue Context
The generic PG loader only performs a size-limited `memcpy` when versions match; it does not migrate two-dimensional arrays. Either bump the layout PG version so incompatible data resets safely, or add an explicit migration that copies each old layout row into the matching new row and initializes the Terrain AGL slot.
## Fix Focus Areas
- src/main/io/osd.h[382-383]
- src/main/io/osd.c[235-236]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

💡 Did you know, you can type 'qodo, fix this' on a finding and the fix lands right on your PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗